The present invention relates to a method and a system for Domain Name System (commonly referred to as “DNS”) based retrieval of service instances.
DNS provides a key service on a network, such as the Internet, in translating queries for domain names, which represent text-descriptive resources, into network addresses that are usually represented by a series of digits. For instance, the DNS is the name resolution system applied in the Internet. It is used to resolve names to Internet Protocol (referred to as “IP”) addresses and vice versa. Newer approaches, such as DNS-based Service Discovery (referred to as “DNS-SD”) described in the DNS-SD draft “DNS-Based Service Discovery” (http:tools.ietf.org/pdf/draft-cheshire-dnsext-dns-sd-10.txt), propose to use the DNS also for the discovery of services, such as printers.
The DNS-SD draft defines a set of specific rules and methodologies for querying a DNS server, but uses already existing DNS resource record (RR) types. In addition, the DNS-SD draft defines a basic syntax to store additional information regarding a service. The DNS RR are named and structured to facilitate service discovery. Therefore, given a type of service that a client is looking for, and a domain in which the client is looking for that service, this allows clients to discover a list of named instances of that desired service, using standard DNS queries.
DNS-SD defines a service instance as a concatenation of <Instance>.<Service>.<Domain>, wherein the <Domain>part represents the DNS subdomain in which the service instances are registered, the <Service> part identifies the service types according RFC 2782 (http://tools.ietf.org/pdf/rfc2782), and the <Instance> part names the service instance.
Service types (<Service>) may include two levels of hierarchy and follow the general convention of [_subtype._sub.]_type._proto, where “_proto” denotes the IP transport protocol used, “_type” names the service type, the keyword “_sub” indicates that a second level of hierarchy is available, and “_subtype” names the service subtype.
DNS-SD uses the following resource record types to represent services:                SRV RRs: store the individual service instances, i.e. resolve from the service instance to the host and have the following form when reduced to relevant arguments (left: argument of query, middle: type of query, right: response to query):            <Instance>.<Service>.<Domain> SRV <Host> <Port>;            TXT RRs: store additional information regarding a individual service instance, i.e.            <Instance>.<Service>.<Domain> TXT <“Arbitrary text attributes”>;            PTR RRs: link the type of a service with the individual service instance, i.e.            <Service>.<Domain> PTR <Instance>.<Service>.<Domain>.
For each service instance, an SRV and a TXT RR are stored in the DNS. The SRV RR is basically used to resolve the host and port of the service instance. The corresponding TXT RR may contain additional information about the specific service instance. The content of the TXT RR is formatted as a key/value pair with the first equal sign (“=”) as separator (e.g. “papersize=A4” for a printer service). The TXT RR may contain multiple key/value pairs. In binary representation each key/value pair is stored with a length field preceding the content. The PTR RR is used to resolve a service type to the individual service instances, i.e. querying for all web servers within a domain might be accomplished with a DNS query for the service type “_http._tcp.<Domain>” and will result in a list of all specific web server instances.
A major problem of the DNS is the size limitation of answers to 64 kB, which limits the number of services of a single category in a domain to approximately 700. This limitation is a main obstacle for larger IP based systems. For instance, a large building automation system may include 5000 devices with 500000 objects/services.
For overcoming this problem, some solutions have been proposed, such as                Engineering and database on a management station;        Web Services Discovery;        Lightweight Directory Access Protocol (LDAP).        
Unfortunately, such solutions require additional infrastructure or are not flexible enough for being efficient. Even if they might be used for a less limited service discovery, they need additional effort in terms of time and/or equipment, since the existing infrastructure needs to be extended to implement these solutions. Moreover, the administrators of the IT infrastructure that is used to network the building automation and control networks (BACnet) devices may not allow usage of the above-mentioned protocols.